1. Field of the Invention
The present invention relates to the multitask processing apparatus which divides an application program into plural task and executes a parallel processing of plural tasks as whole in order to realize a function of the application effectively.
2. Description of Related Art
Hitherto, the real time operating system has become indispensable as management software in order to execute plural tasks in parallel. The operating system will be abbreviated as "OS" hereinafter in the specification. In general, the real time OS possesses a number of functions such a task management function for starting a task and completing the processing, a function of synchronous communication between tasks which controls the waiting period between tasks and the transmission-reception of data, a function relating to the interrupt, other memory areas management function and a time management function.
When an application program makes use of the real time OS, the program demands a processing of each function with respect to the real time OS. The demand of the processing is called a "system call", and the operation of generating the demand of the processing is called a "generation of the system call". An example of the generation of the system call will be explained.
A system call processing can be generally divided into three parts, that is, task save processing, internal processing and dispatch processing as illustrated in FIG. 1. In the part of the task save processing 100, the real time OS utilizes sorts of registers for the system call processing so that the execution environment of the task such as informations of the registers when the task generates a system call (called "context" hereinafter) is saved to an area inherent to the task, that is, task control block (called "TCB" hereinafter). In the part of the internal processing 101, the processing for the realization of the functions which are objects of the system call is executed. In the part of the dispatch processing 102, the processing is executed in the form that the task with the highest priority order to be next executed is selected from the tasks in an executable state, and the context saved in TCB of the selected task is returned to the registers in order to shift the control from the real time OS to the task. FIG. 1 shows a processing of a system call which demands the suspension of the designated task in the conventional multitask processing. The tasks transits four states, that is, a dormant state, an executable state, an execution state and a waiting state. It is assumed that the priority order of the task 1 is prior to that of the task 2. The execution task 1 designates the task 2 in the executable state and generates a system call demanding the suspension. The real time OS obtains the right of use of the central processing unit (called "CPU" hereinafter) of the computer by the generation of a system call of the task 1 so that the context of the system call generating task 1 is saved to TCB 1 which the task 1 possesses. Subsequently, the area representing the state of the task held in TCB 2 of the task 2 (called "task status" hereinafter) is set to the reopen demand waiting state in order to suspend until the issue of the reopen demand, and the task 2 is eliminated from the registration of the area which manages executable tasks (called "ready queue" hereinafter). In the dispatch processing, the real time OS selects the task 1 as the task to be next executed, based on the ready queue, and the context of the task 1 saved in TCB 1 of the task 1 is returned on the CPU. The right of use of the CPU is shifted to the task 1. Thus, the processing of the system call is finished.
In the conventional multitask processing apparatus as mentioned above, the tasks of the application program and the real time OS of the management software utilize equally the CPU resource. Therefore, at the execution of the real time OS, the context of the execution task must be saved, which will increase the execution time of the real time OS, that is, the overhead so that the performance of the whole system is lowered. The high speed processing of the real time OS is required for the improvement of the real time characteristic of the system.
FIG. 2 shows an example of the transmission-reception of data between two tasks. For the transmission-reception of data between tasks, a common buffer, called mailbox, is generally used. A task A, in steps 200-300 generates a transmission data and transmits a pointer to the data as parameter to the mailbox number 1 (#MBO-1) by a system call SEND-DATA. Here, it is assumed that the parameter of the system call SEND-DATA is a register RO.
A task B, in steps receives the data transmitted from the task A through the mailbox number 1 and executes the following processing based on the received data by means of a system call RECEIVE-DATA. It is assumed that a pointer to the received data is stored in the register RO. In the case that the transmission data does not exist at the generation of the system call, a task B becomes a waiting state with respect to the mailbox number 1 and the processing is temporarily reserved, so that the control is shifted to the other task.
FIG. 3 shows the processing steps 301-317 of each system call. The conventional real time OS is realized by combination of instructions as system software. Therefore, it is necessary to save the environment or context which is necessary to the execution of a program such as a register and a program status word (called "PSW" hereinafter) of the task which generates a system call at the head of the processing before the execution of each system call. The areas for the save of the context which are called a task control block or TCB are generally reserved on the memory for all tasks respectively, so that, at the generation of a system call, the context of the task is saved in the TCB corresponding to the task which generates the system call.
After the processing of the system call, the task with the highest priority order is selected and the control is shifted to the task. This is called "dispatching" as mentioned hereinbefore.
Concretely, by the system call RECEIVE-DATA, the context of the task which generates a system call is saved to TCB at the start. Then, the state of the mailbox is judged by the mailbox number represented by a parameter. When the data has been transmitted, a pointer to the data is stored in the area corresponding to the register RO in the TCB of the task which generates the system call and the dispatching is executed. In the case that the data is not transmitted, the task which generates the system call waits for a mailbox and the task status of the generating task becomes a waiting state. The task status is generally assured in the TCB of each task as well as the context of the task.
Then, an identifier of the task with respect to the mailbox is added in order to show that the generating task becomes a waiting state with respect to the mailbox represented by a parameter. Thereafter, the real time OS manages a structure or ready queue for the processing of all executable tasks in a bundle which is generally assured on the memory. The task which has become a waiting state is not an executable state so that the task is eliminated from the registration of the ready queue. After the elimination, the similar dispatching processing is executed.
Subsequently, in the case of the processing of a system call SEND-DATA, as well as that of other system calls, the context of the task which generates the system call is saved to the TCB. The state of the mailbox indicated by the parameter is judged. When there is no waiting task, a pointer to the data area indicated by the register RO is stored in the mailbox and the dispatching processing is executed.
In the case that a waiting task exists with respect to the mailbox, the task status of the waiting task is set as executable and the identifier of the task is eliminated from the mailbox and registered in the ready queue. Then, a pointer of the transmitted data is stored in the register RO of the task and the dispatching processing is executed.
FIG. 4 shows a flowchart of the execution of the task A and B by steps 400 and 401 illustrated in FIG. 2 by executing the above mentioned processing.
It is assumed that the priority order is set in the tasks respectively and that the task B is prior to the task A. First, the task B is activated in the execution condition and generates a demand for the reception of the data from mailbox #MBO-1 by the system call RECEIVE-DATA. At this time, the data is not transmitted to the mailbox so that the generating task transits a waiting state and the control is shifted to the task A. After generating data, the task A transmits the data to the mailbox #MBO-1 by the system call SEND-DATA. In the mailbox #MBO-1, the task B has already become a waiting state so that the transmission data is sent to the task B. Thus, the task B is dissolved from the waiting state and changes to the executable state. In the case of the dispatching processing, the task B is selected and the control is shifted to it because the priority order of the task B is prior to that of the task A.
As mentioned above, the conventional real time OS which is principal software for realizing the multitask processing is realized by the combination of instructions so that the processing is sensibly complicated. The number of steps required for the processing depends on the scale of the OS. However, several ten to several hundred steps are generally required for the processing of each system call.
Further, the save of the context after the first and last processing of the OS and the return processing become necessary in order to prevent the destruction of the context of tasks because the processing of each task and that of the OS utilizes common registers and other hardware resources. It is general that several ten to several hundred steps are required for the save, the return processing and the dispatching processing.
The real time OS must respond to a number of events in a real time as its name represents. In the present condition, however, it is impossible to obtain the performance which can satisfy enough demands of the application program because the processing is complicated. In the case of evaluation of the performance of the real time OS, the overhead of the system call often becomes a problem. The overhead is a time from the generation of the system call to the return of the control in the task. In the above mentioned example, assuming that the number of steps required for the generation of system calls, the execution of each system call after the save of the context and the return processing and the dispatching processing is 200, the mean number of clocks of the execution of an instruction is 10 clocks, and if the action frequency is 5 MHz, the mean overhead becomes 400 microseconds.
This time is not negligible in the application field which needs particularly the real time characteristic. Accordingly it is a problem to reduce the overhead for the planning of the real time OS.
Further, in the application system which utilizes the real time OS, it often happens that the flow of the processing is changed at the opportunity of several interrupts, so that it is necessary to improve the response characteristic to the interrupt. On the contrary, the OS which controls the multitask processing operates a common data structure which manages the state of tasks respectively and tasks in executable state according to the priority order. Accordingly, there are many parts which must be guarded from the interrupts which are asynchronously generated from the external in order to prevent the competition of accesses.
The example of the error operation in the case that there is no guard against interrupts will be concretely explained. It is assumed that an interrupt is generated at the level of INT by the system call RECEIVE-DATA shown in FIG. 3. FIG. 5 represents the interrupt processing routine started by the interrupt INT. The interrupt processing routine is generally operated in the state where the interrupt cannot be executed, so that it generates a system call of demanding the dispatching 501 after the simple processing 500.
Now, when the interrupt is generated at the level INT during the processing of the system call RECEIVE-DATA, the system call generating task is in the process for changing to the waiting state, the task status becomes a waiting state and the identifier of the task is registered with respect to the mailbox. The interrupt processing routine to which the control is shifted generates a dispatching processing demand after the simple processing. In the dispatching processing of the OS, ready queues are judged and the task at the highest priority order is selected. Then, the task which generates the interrupted system call RECEIVE-DATA is not eliminated from the registration of the ready queue. Accordingly, the generating task is selected again by the dispatching processing and returns to an execution state. The task which reopens the execution judges that the data has been received by the generation of the system call RECEIVE-DATA and continues to execute the processing. However, the pointer to the received data becomes an incertain value so that the following operation is not assured.
Accordingly, it is necessary to guard against the interrupt in the major part of the processing in case of the system call as mentioned in the present invention.
The more the guard parts exist, the more the stability of the whole system is improved. On the contrary, the interrupt response characteristic is lowered which is a problem, too, in the planning of the real time OS.